Processing systems commonly support interrupt mechanisms, wherein an interrupt may asynchronously halt or suspend a current execution thread or instruction stream of a processor, such that the interrupt may be serviced. An interrupt may be generated from various sources, including on-chip or off-chip external devices. Interrupts may also be generated internally within a processor or CPU, such as from one or more threads in a multi-threaded processor.
In order to service an interrupt, an interrupt service routine (ISR) may be executed by the processor receiving the interrupt. Each interrupt may include a particular ISR associated with the interrupt. Because interrupts may be received from various sources, an interrupt controller is commonly used to handle the tasks of receiving the interrupts, prioritizing among several outstanding interrupts, and tracking the status of pending interrupts such that a processor's availability to process new interrupts may be ascertained. In order to keep track of interrupts and associated sources and ISRs, a vectored interrupt controller (VIC) is known in the art to track vectored addresses associated with each interrupt, such that the VIC may be enabled to provide the processor servicing the interrupt with the associated ISR.
In the case of multi-threaded processors configured to execute two or more threads in parallel, priority levels may be dynamically or statically assigned to the threads, in order for an interrupt controller to determine which thread should be interrupted in order to service an interrupt. A first level or L1 interrupt controller may be configured, for example, to handle interrupts related to a processor core, such as a multi-threaded processor. A second level or L2 interrupt controller may be configured, for example, to handle interrupts from external devices or interrupts on a global scale. The L2 interrupt controller may be in communication with the L1 interrupt controller through system buses such as AHB/AXI to direct interrupts accordingly from the L2 to the L1 interrupt controller. Two-level interrupt controllers, such as L1 and L2 interrupt controllers, may find several other applications in processing systems, as will be recognized by one of ordinary skill in the art.
With reference to FIG. 1, a conventional implementation of a two-level interrupt controller is provided. L2 interrupt controller 102 may communicate an interrupt over bus 108 to L1 interrupt controller 104, which may be attached to core 106. As shown, core 106 is in direct communication with only L1 interrupt controller 104, and not L2 interrupt controller 102. Initially, L1 interrupt controller 104 may receive a first interrupt from L2 interrupt controller 102. Thereafter, the processing of subsequent interrupts may be handled in one of two ways, for example, based on processor resources.
In a first scenario, immediately upon receipt of the first interrupt, core 106 may provide an indication to L2 interrupt controller 102, through L1 interrupt controller 104, that the core 106 is ready for a new interrupt. L2 interrupt controller 102 may then send the processor core a second interrupt if a second interrupt is pending at L2 interrupt controller 102. For instance, if core 106 is configured as a multi-threaded processor, the first interrupt may be serviced by a first thread of the multi-threaded processor, and a second thread may be in WAIT state, and available to process a second interrupt. In this instance, the multi-threaded processor may provide an indication L2 interrupt controller 102, for example, via L1 interrupt controller 104, that L2 interrupt controller 102 may send a second interrupt, immediately after the processor core receives the first interrupt.
Alternately, in a second scenario, core 106 may provide indication to L2 interrupt controller 102 to defer sending any new requests until a later point in time or until further notice. Once again, if core 106 is configured as a multi-threaded processor, all the threads may be busy, and the real-time operating system (RTOS) associated with the processor core may require a time delay in order to determine which thread to interrupt. For example, the RTOS may determine which hardware thread is running a software thread with the least priority, and designate that thread as the lowest priority software thread, such that L1 interrupt controller 104 may direct a second interrupt from L2 interrupt controller 102 to the lowest priority software thread. The determination of the lowest priority software thread may incur significant time delay, and correspondingly, the rate at which interrupts can be processed suffers degradation.
Moreover, in conventional data processing systems, information regarding interrupts, such as vectored addresses associated with the interrupt's ISR, is communicated between L2 interrupt controller 102 and L1 interrupt controller 104 over an Advanced Microcontroller Bus Architecture High Performance Bus (AHB). The process associated with reading the AHB in order to retrieve the above information may add a significant delay to the interrupt latency, and thus further impact the rate at which interrupts are processed.
In order to mitigate the aforementioned problems associated with conventional interrupt handling, there is a need in the art for solutions including low latency two-level interrupt controllers.